1. Field of the Invention
The present invention relates to the access from users to services or resources over the Internet, and particularly to the interaction between entities on a communication network through SIP (Session Initiation Protocol).
This invention relates in particular to the access to session- and subscription-based services through SIP (Session Initiation Protocol).
2. Background of the Invention
Different types of Internet-based services exist, such as transaction-based services (e.g. e-commerce), information services (e.g. web browsing), session-based services (e.g. video streaming, inter-personal multimedia communication) and subscription-based services (e.g. get updated about presence information), messaging-based services (e.g. instant messaging).
The Internet Engineering Task Force (IETF) has standardized in June 2002 the Session Initiation Protocol (SIP) (as available in the Request for Comments collection, RFC3261, by J. Rosenberg et al., on Jun. 10, 2004 at the complete URL http://www.ietf.org/rfc/rfc3261.txt) that provides a way to establish and control multimedia sessions over IP, as well as a framework for event notification and subscription management (SIP event framework) called Session Initiation Protocol (SIP)-Specific Event Notification (as available in the Request for Comments collection, RFC3265, by A. B. Roach, on Jun. 10, 2004 at the complete URL http://www.ietf.org/rfc/rfc3265.txt).
SIP-enabled multimedia communications include, but are not limited to, audio/video, data, messaging and event notification (such as presence) communications between two or more entities.
SIP protocol defines several types of methods (SIP methods) and related text-based messages (hereinafter SIP messages) between two entities, typically a client application and a server.
Each type of SIP method defines a different service model. SIP has, amongst others, service model types of:                session (using the INVITE SIP method);        subscription (using the SUBSCRIBE SIP method);        asynchronous notification (using the NOTIFY SIP method); and        messaging (using the MESSAGE SIP method).        
For each type of service model, SIP protocol defines some basic message interactions between clients and servers, including message type and format. A SIP message includes some required information (for example some SIP headers) and can be extended with optional information depending on the SIP method and the service to invoke.
As an example, a user wishing to view a movie trailer would typically require its client application to use an INVITE method and to send an INVITE message to start a video session with a movie server. In another context, a user willing to be updated with information, e.g. about local weather, will use a SUBSCRIBE method by triggering a SUBSCRIBE message from its client application to a server, e.g. a weather forecast server.
Currently, one standard way to describe a service invocation through the SIP protocol between a client application and a server is to define a SIP Uniform Resource Identifier (SIP URI) where to invoke the service, and optionally the SIP method and the required input parameters with their position in the SIP message (e.g. “sip:weather@mycompany.com;method=SUSBCRIBE?event=weather&p-city=turin” defines a SIP URI, i.e. sip:weather@mycompany.com, and specifies that the SIP “SUBSCRIBE” method has to be used and that an “Event” header with value “weather” and a “P-City” header with value “turin” have to be inserted in the SIP SUBSCRIBE message.
By clicking on a hyperlink pointing to the SIP URI on a web page the client application associated with SIP hyperlinks of the type SIP-URIs constructs the SIP message with all these parameters, confident that it is exactly the format expected by the service. The input SIP message can be sent to the service and be processed at the server location in the right way.
However, using the above mechanism according to the SIP standard, the client application does not know the exact semantics of the answer from the service a priori without invoking the service and actually receiving the answer.
In other words, the client application will see what the response format is only when it receives a response from the service it has invoked.
Moreover, the comprehension of output data and parameters sent by the server to the client application may not be trivial, since some information can be included in headers or body of the SIP message and unknown to the user.
Due to these limitations, a SIP client application may not handle and process answers coming from a server automatically and/or correctly. This means that a SIP client application needs to conform to the answer it is going to receive.
Additionally, the above mechanism does not allow defining optional information that may or may not be sent by the client application when invoking the service.
Moreover, the above mechanism explicitly applies for a single service provider entity (responding at the specified SIP URI) and not to a plurality of provider entities or services.
In the context of session- and subscription-based services, formalisms are known to describe these services only for server's internal use.
Amongst them, scripting languages like Call Processing Language (CPL) (as retrieved on Jun. 10, 2004 at the complete URL http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-09.txt), whose last version has been defined in April 2004 by the IETF, defines rules for processing session-based services in XML (eXtensible Mark-up Language).
This description, however, only defines the server's internal service logic and not the remote invocation mechanisms from the client application.
In a similar way to CPL description, Sun Microsystems and Dynamicsoft Inc. published in February 2003 the final release of SIP Servlet API v.1.0 Specification (available on Jun. 10, 2004 at the complete URL http://jcp.org/aboutjava/communityprocess/final/jsr116/index.html).
The SIP Servlet is a Java-based service logic executing on a SIP server that can listen to SIP messages coming from clients. The SIP servlet specification defines deployment descriptors for SIP servlets: these descriptors are XML-based files stored locally on a server that map an input filter based on a SIP message with a predefined SIP servlet. Whenever a SIP message arrives from a client application to the server, a SIP servlet container checks whether the message matches a filter defined in a descriptor. If so, the servlet container automatically triggers the service logic that corresponds to the matching filter in the descriptor.
This description is limited in the definition of input parameters and does not include any information about the output of the service toward the client application.
In the above-mentioned two formalisms, if a client application sends a SIP message to a server, once more it will not know exactly what will be the output of the server, if any, and thus it cannot handle and process answers correctly.
Furthermore, SIP event framework defines service model of asynchronous notification in subscription-based services, i.e. it allows a client application to subscribe to event occurrences during a certain period of time and to be dynamically notified by a server of each event occurrence during the period. The notification is sent by the server at times decided by the server.
SIP event framework suggests that the notification comprises data formatted according to a so called “SIP event package”. The SIP event framework suggests the same approach for subscription to event occurrences.
SIP event framework is explicitly independent from the actual service data that is requested by the client, so that these mechanisms are open to apply to notification of any kind of event and related service data, for example online discovery/retrieving of specifications and/or availability information regarding the services currently provided by a server.
International Publication WO 2004/059502 A1 “Content and service registration, query and subscription, and notification in networks”, published Jul. 15, 2004 describes a system and method using SIP protocol for discovery of availability and capability of services or content within a local network. This mechanism envision the client application to query explicitly for a specific service, and get notified about its providers and their specific capability information (typically SLP-based information in a local network).
The above known art does not apply to an unknown plurality of services, nor to telecommunication networks and services.
US Publication US 2004/0153547 “Service provisioning in a communication system”, published Aug. 5, 2004 describes a mechanism using SIP protocol for provisioning event package descriptions to be used for subscriptions to services. The above method explicitly refers only to event packages description provisioning from a server to a client.
The WO 2004/059502 A1 and US 2004/0153547 fail to teach how a client application will receive answers by a server when invoking a service, it neither teaches how answered information is organized.
As an example, a user wishing to be updated with information about local weather, and subscribing at a server to a weather forecast service, will neither know how notification will occur, i.e. it will not be informed about the type, format, output parameters and transport protocol of the answer he should receive, before the notification itself, nor when updating information will be sent by the server.
Thus, on the basis of the known solutions in a SIP-based context, Applicant believes that formalisms defining session- and subscription-based services lack of a mechanism to describe semantics of interactions both from client applications to SIP resources offering these services and vice-versa.
To summarize, Applicant believes that the closest prior art related to SIP session- and subscription-based services fails to make available standard ways of describing how to invoke a SIP service, receive and understand the response. Current solutions to describe the operation or the invocation of such a service only cover a single aspect of this interaction, i.e. the input interaction between a client application and a server, but fail to teach how the server is going to act in response.